Chapter 24
Finding the Right Responsibility
"Every new system should begin with a responsibility—not with an implementation."
Why This Chapter Exists
One of the most common mistakes when extending a framework is beginning with implementation.
A new gameplay feature appears.
A new class is created.
Additional functionality is added.
The feature works.
Over time, however, the architecture becomes increasingly difficult to understand.
Responsibilities begin to overlap.
Subsystems slowly lose their original purpose.
The Cube Framework deliberately avoids this pattern.
Before introducing any new system, it first asks a different question:
What responsibility does this system actually own?
Responsibilities Come Before Classes
Classes are implementation.
Responsibilities are architecture.
This distinction is fundamental.
A responsibility describes why a system exists.
A class merely describes how that responsibility is implemented.
For this reason, architectural design within the Cube Framework always begins with responsibilities.
Implementation follows afterwards.
Never the other way around.
Looking for Existing Responsibilities
Not every new feature requires a new subsystem.
Often, the required responsibility already exists.
A new authored asset still belongs to the Definition Layer.
A new validation rule still belongs to Validation.
A new Build step still belongs to the Build Pipeline.
A new runtime representation still belongs to Runtime Assembly.
Rather than creating parallel systems, new functionality should naturally integrate with the existing architectural responsibilities whenever possible.
Recognizing New Responsibilities
Occasionally, new functionality genuinely introduces a responsibility that does not yet exist.
This should be treated as an architectural event.
A new responsibility should only be introduced when an existing one can no longer describe the problem without becoming overloaded.
This keeps the architecture both stable and adaptable.
Adding responsibilities should therefore remain intentional rather than reactive.
One Responsibility, One Purpose
Every architectural responsibility should answer one clear question.
Examples include:
- How is authored knowledge described?
- How is runtime prepared?
- How is runtime assembled?
- How is runtime synchronized?
- How do systems communicate?
Whenever a subsystem begins answering multiple unrelated questions, it has likely exceeded its architectural responsibility.
This is often the first sign that further decomposition is necessary.
Responsibilities Grow Carefully
Growth is expected.
Complexity is expected.
Architectural drift is not.
The Cube Framework encourages responsibilities to become more capable over time.
It discourages them from becoming broader.
Capability and scope are not the same.
A responsibility may become increasingly sophisticated while continuing to solve the same architectural problem.
Maintaining this distinction allows systems to evolve without losing their identity.
Respecting Architectural Boundaries
Responsibilities naturally create boundaries.
These boundaries should be treated as design tools rather than restrictions.
Every boundary protects a subsystem from responsibilities that belong elsewhere.
As a consequence, responsibilities become easier to understand.
Testing becomes easier.
Documentation becomes clearer.
Future extensions become significantly more predictable.
Design Note
Whenever you believe a new subsystem is required, avoid asking:
"What should this class do?"
Instead ask:
"What architectural responsibility does this subsystem exist to protect?"
Responsibilities should define systems.
Systems should never define responsibilities.
Framework Law XXIV
Within the Cube Framework, every subsystem exists because it protects a single architectural responsibility.
When responsibilities remain focused, the framework remains understandable.
Looking Ahead
Once responsibilities have been identified, the next step is deciding where new knowledge should enter the framework.
The next chapter explores why every Cube module begins with Definitions and how extending authored knowledge naturally extends the architecture itself.
Revision History
Version 1.0
Initial publication.